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ABSTRACT 

A study looked at four groups of mostly senior 
graphic and industrial design students in their final semester 
capstone course — a collaborative studio project intended to give them 
the opportunity to apply their design expertise to real-world 
problems for real clients. The study examined the ways in which one 
of these groups used arguments to handle the dev ^.opmental and 
communication-based difficulties of approaching an open-ended 
project. Data were collected through structured and semi-structured 
interviev/s, direct observations, and archived documents and drawings. 
The scenario called for the participants to design the next family of 
Apple computers; the largest computer was to be a desktop sort and 
the others hand-held or wearable. A vocabulary developed by the 
observation team proved helpful in evaluating the functioning of the 
student; design team: requirements (features considered necessary for 
the proposed design); criteria (the norms that are necessary to 
fulfill the design requirements and the relative weight that should 
be given to each of these norms); models (prior designs that can 
serve as potential analogs to the current design); plans (which exist 
at the confluence of requirements, criteria and models); and 
prototypes (more costly than plans, they are refined enough to 
"work"). An examination of how one group worked through these various 
stages shows the enormous pot ent ial for conflict, frustration and 
confusion. Generally, however, the student group worked smoothly, 
especially after plans and prototypes were on the table. (TB) 
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Introduction 

Throughout this project described in these three papers, we have focused 

CO 

t$ on the role of argument in collaborative efforts that routinely cross visual and 

S verbal modalities. While David Fleming's paper told of the importance of 

CO 

q considering the client 's requirements in design activity, and Ann Sinsheimer- 

Week's paper told of the importance of giving attention to the legal require- 
ments in design situations, this paper seeks to describe how a group of 
designers employed arguments surrounding verbal and visual artifacts to 
respond to a complex and open-ended design problem. 
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Participants 

My study looked at four groups of mostly senior graphic and industrial 
design students in their final semester capstone course — a collaborative stu- 
dio project intended to give them the opportunity to apply their design exper- 
tise to real-world problems for real clients. All were graduating seniors or 
master's students who, with this rare opportunity for exposure and recogni- 
tion in their field, were excited about the task. In all, I observed thirteen stu- 
» dents and five professors. 

M The instructors assigned the class into four groups; initially two with four 
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people, and two with three people. All teams had at least one graphic 
^ designer and one industrial designer, and some also had professional writers. 

My description in this paper will focus primarily on one group of four stu- 
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dents (with two industrial designers and two graphic designers). However, I 
believe similar observations could be made about the other groups that I also 
watched throughout the semester. 

Methodology 
Data Collection 

To collect data on the designers' use of argument in collaborative design 
problems, I used an observational methodology to limit the amount of inter- 
vention on my part and to collect a natural and rich record of design activity 
in the widest array of contexts possible. I used three methods to collect my 
data: structured and semi-structured interviews, direct observations, and 
archived documents and drawings. 

Vocabulary for Analysis 

To describe common rhetorical practices across the three projects 
described in this panel and to provide a framework for other researchers and 
practitioners who study designers to potentially test, modify, and use to 
explain loci of argument in collaborative design, my colleagues and I con- 
structed a vocabulary of five terms — requirements, criteria, models, plans, 
and prototypes — by attempting to describe the loci of convergence or diver- 
gence of verbal and visual arguments common across our collaborative 
design projects. These terms also may be thought of as describing points of 
contention about which agreements and disagreements in design turn. 

Requirements. 

Requirements are the features considered necessary for a proposed design. 
External requirements are often set by the client — in my study, Apple Com- 
puter Corp.who had invited several top design schools to compete in a con- 
test asking them to design the next family of Apple products. Because of the 
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contstraints of the contest, Apple only provided a one-time, one-way commu- 
nication to the designers stating their requirements for the project. The 
designers also had other potential sources of requirements, their instructors — 
all having input to the final grades of the students. Since there were so many 
voices of clients in my study, the potential for discord about the perceived 
requirements for the project was strong. Indeed, the designers seemed at 
times to never know exactly who spoke most representatively for "the cli- 
ent." 

In contrast to external requirements, designers' requirements are require- 
ments held by members of the design team. In an obvious sense, the require- 
ments of the designers must overlap with the external requirements of the 
client. But the mapping between the two sets of requirements is complex and 
subtle, often requiring that designers make inferences about their client. 

Criteria. 

Design criteria are the "norms" of proceeding that are necessary to fulfill 
the designers' requirements. Such norms are established from years of train- 
ing and experience and often sound as innocuous and obvious as mom and 
apple pie: good design is simple, uniform, appealing, and so on. But such 
norms are only a small part of the contextualized knowledge needed to oper- 
ate as a designer. Rules of application are usually hidden from the statement 
of norms; and, taken as single words, criteria can sound contradictory. For 
example, "surprise" may be a valued element of design, but equally valued 
may be "predictability," Attached to specific patterns in specific contexts, 
however, such criteria are not in fact contradictory; experienced designers 
can (so it seems) fill in the missing patterns and contexts needed to keep them 
from being contradictory. 

Designers, then, may fail to meet a criterion not because they fail to 
believe in its worth, but because they fail to give it the priority it deserves. 
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Design criteria may be thought of as "top-down" points of instantiation. 
While giving the designer far less information than needed to finish the 
design, they nonetheless offer useful starting points from which to plan their 
design. 

Models 

Depending on their previous experience, designers can retrieve from their 
memories a catalog of prior designs that can serve as potential models or ana- 
logs to the current design. Designers may look to their memories for models, 
or as in the case of the Apple Computer project, they may supplement their 
memories with external research. Unlike criteria, which guide the design 
from the top down, models guide it from the bottom up. The advantage of 
models in directing a design is that models are complete; they leave nothing 
to the imagination about how the smallest detail is to be filled in. The disad- 
vantage, however, is that because of the completeness of detail of one model, 
the model may not "transfer" to the new design problem. The model being 
"transferred" may have been designed under different requirements and with 
different criteria as priorities. 

Plans 

Plans exist at the confluence of requirements, criteria, models, and the 
context for the design. Plans go by many names: sketches, doodles, draw- 
ings, mock-ups, story boards, outlines. Plans are more concrete and visible 
than criteria and more flexible than design models. They provide useful 
points of focus against which members of the design team can check their 
potentially inchoate images of the design project with those of other mem- 
bers. 

While plans are visible enough to command the undivided attention of 
everyone on the team, (that is, they can focus the cognition of individuals 



ERIC 



Collaborative Invention in Computer Prototype Design: Negotiating Group Processes and Arti ^ctsOctober 21 * 1994 



5 



4 



onto a single visual field), they may also be produced by everyone on the 
team, and produced frequently. The introduction of a visual plan, in other 
words, may become a frequent enough non-event that the plan only achieves 
casual and uneven processing, given no more detailed and focused attention 
than the words the designers volley back and forth, which occurred in the 
early stages of the Computer Project. 

Prototypes 

Prototypes are plans that are refined enough to "work." They are thus 
more costly than plans, usually requiring the effort of multiple individuals. 
Prototypes, then, benefit convergence because they command the sustained 
focus of the entire team. Because of the cost of producing and attending to 
them, however, prototypes may have the effect of cutting off alternative 
design options, at least temporarily. Prototypes are also the first representa- 
tion detailed enough to be evaluated from the user's perspective. Prototypes 
benefit convergence between the designers' requirements and external 
requirements. 

Designers may role-play the user and imagine the user's experience with 
the product through scenario-based reasoning. As mismatches are discovered 
between the user's expectations and the actual functioning of the prototype, 
the prototype is revised to eliminate them. 

Let me give you an example using all five terms. A requirement of the 
design was that "the computer should be interactive and pen-based." A crite- 
ria of the designers was that "keypads are not good unless you can feel 
them." An example of a model the students used was a pocket-sized note- 
book, which was used to model the size of the palm-top computer. An exam- 
ple of plans were sketches or doodles providing a few views of a palm-top 
computer. And finally, an example of a prototype was a foam block that was 
sculpted by the designers to look like a palm-top computer. 
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Having illustrated some key concepts to describe the collaborative argu- 
ment employed in the group I observed, I will now describe for you how 
these key concepts describe the loci of collaborative argument in the design 
problem facing these designers. 

Collaborative Argument in the Apple Computer Project 

The designers in this study appeared to illustrate relatively successful 
example of collaborative design: an efficient transition from research to plan 
to prototype to final design. The ease of forward and productive movement 
which this group exhibited may be explained in part by the relative absence 
of the client and the open-ended nature of the task. In the rest of this paper, I 
will attempt to illustrate, using that vocabulary our research team has con- 
structed, how even though their effort was for the most part successful and 
efficient, the group of designers faced a complex, relatively open-ended task 
assigned by a distant client who contacted them once and modified by the 
often contradictory interpretations of the instructors of the course. 

In a letter inviting the designers to participate in their contest, Apple Com- 
puter company challenged them to design a family of computer products. 
They spelled out their requirements in this letter — the designers were asked 
to: 

prototype the interface designs and physical forms for at least three 
computers. Each computer device should have a different function but 
be able to work as a part of the same family of interconnected comput- 
ers. The largest should be a traditional office computer (a desktop 
machine); the others should be hand-held, even wearable. The purpose 
of this project is to design a family of computers that have different 
functions but all work together with a consistent look and feel. 

Winning designs would be featured in a leading design journal and their 
creators flown to Apple headquarters to present their work. 
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In the absence of a strong client presence, the instructors played an 
important role in representing project requirements. For example, they told 
students not to make their designs too bulky or heavy, to provide drawings of 
the inside of the machines, and to make the look and feel of the designs 
match their cost. But two additional requirements seemed contradictory. 
Students were alternately encouraged to create blue sky interfaces, ones that 
were unconstrained by present technology; and then to make sure their 
designs were feasible, grounded in current (or soon to be current) technology. 
This shifting of perspectives — this incompatibility or dissonance — was frus- 
trating to the students. Often they would present their work to the professors 
and be criticized for not being creative enough, not blue sky enough. Later, 
they would return with more "creative" ideas, only to be asked if their 
designs could be constructed with existing technology. 

Research Efforts 

Early in the semester, the instructors urged the students in each team to 
select a design idea and conduct research in that area. As a result, the stu- 
dents spent most of their time in team meetings, discussing first their research 
and then their proposed designs. Early on, these discussions centered on 
Apple's external requirements. As work progressed, however, the students 
began proposing requirements and specifications of their own, such as: 

• two of the computers should be portable, one smaller than the other; 

• all features should be controlled by the screen, not outside buttons; 

• the computers should be interactive and pen-based; 

• the computers should share a name to show they are members of one fam- 
ily. 

The fact that a requirement was proposed by a designer, however, did not 
make it a requirement for the whole group. In the beginning of the project 
especially, the designers would often suggest a requirement that would be 
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met only with silence, and the group would simply move on to another issue. 
At other times, as in the example shown, the requirement would be rejected 
outright, sometimes with the argumentative help of what we have called 
design criteria: 

Jill: We could have a recessed keyboard. 

Mary: I don't understand what you mean by recessed. Is it sort of like 
a telephone keypad? 

Ned: Keypads are not good unless you can feel them. 

As their work progressed, members of the group often argued about these 
verbal requirements. Without connections to a shared physical plan or proto- 
type, however, such discussions only minimally assisted ultimate conver- 
gence on specific ideas and objects. 

The research that the instructors encouraged the students to conduct dur- 
ing the early weeks of the project was intended to acquaint them with state- 
of-the-art computer technology ~ that is, with what we have called models. 
The designers were given topics and then asked to report back to the other 
designers in the class. This research phase lasted for the first five weeks of 
the four-month project. Toward the end of that phase, one instructor urged . 
the designers to begin narrowing their design options by testing ideas against 
what would work out in the world. He asked them to focus on uses for the 
technologies they were developing, to define and solve real problems with 
those technologies. Another instructor urged the designers to role-play, 
entertaining hypothetical scenarios in which people actually used their tech- 
nologies. In this phase, then, models were to be matched to the particular sit- 
uation at hand. 
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current technology. For example, the designers developed a sketchbook idea, 
although they knew that the company was marketing just such a device. 

In sum, then, whereas requirements often seemed to be the crux of group 
arguments, criteria seemed more likely to be shared statements that the 
designers used to establish a common back^iound, a sense of collegiality, and 
consensus in the group. 

Cycling through Plans and Prototypes 

Once students had narrowed their ideas to one or two options, the instruc- 
tors began to urge them to elaborate their ideas through sketching and writ- 
ing, that is, through plans. But the initial efforts of the group to elaborate 
ideas were not through visual plans alone, but rather through a spiraling pro- 
cess in which they used plans — sketches, drawings, and lists, and their group 
discussions to help them to acquire the information necessary to achieve con- 
sensus and then to build more detailed physical prototypes. 

Prototypes would then be evaluated in crits, after which the designers 
would go back to sketches, drawings and lists for the next series of refine- 
ments. The designers were adept at creating highly detailed sketches which 
helped propel the design forward. Physical prototypes were created several 
times in the project, but they were rarely "filled in." That is, at first they con- 
sisted only of foam block carved in some general shape. Gradually, the foam 
became more and more detailed. For the final presentation, the prototypes 
were encased in colored plastic and contained realistic-looking attributes 
such as screens and buttons. These models were costly to create in both time 
and effort. 

Plans and prototypes served, then, to focus the efforts of the design team, 
providing them with a vehicle for debate about requirements and users. Such 
perceptually-shared artifacts, which instantiated a lexicon (terms, names, and 
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From Research into Plans and Protoypes 

Design criteria can serve as filters in process of sorting out requirements. 
One source of criteria is the client, and the company in this case did provide 
the students with a list of criteria for success* According to that list, success- 
ful designs provide for: 

• usability 

• uniqueness 

• feasibility 

• communicability (that is, internally consistent and well presented) 

• logical interpretations 

• clarity of concept (though not necessarily detailed in implementation at 
this stage). 

The instructors reinforced some of these criteria, especially: 

• usability 

• creativity 

• feasibility 

• communicability. 

The designers, meanwhile, tended to emphasize: 

• usability 

• clarity 

• comfort 

• feasibility 

• attractiveness 

" communicability — that is, that form follow function, that the design be 
internally consistent, and that there be consensual justification for all deci- 
sions* 

The designers rarely discussed creativity or uniqueness. In fact, they 
seemed to suffer in the end from too much effort to ground their designs in 
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descriptions) that had previously been unattached to actual objects (but which 
nonetheless helped prepare the group for those objects), helped in turn to 
make sense of the lexicon, pushing the group now to develop, simulta- 
neously, both words (attached to things) and things (attached to words). 
Interestingly, though, as the design activity moved more and more toward 
prototypes, the group met less frequently. When students did meet, they did 
so in subgroups, one assigned to the physical model and the other to the com- 
puter interface. 

Before the fairly rapid and successful spiraling between plans and proto- 
types that occurred in the final weeks of the project, the designers had been 
stuck at a point where they were not able to agree on the attributes of their 
design, and more fundamentally, what they meant when they spoke of partic- 
ular concepts. Once a concrete plan was "on the table," however — a visual 
instantiation of requirements, criteria, and the features of unique situations — 
productive dialogue seemed to increase, and refinements were made. The 
designer who took it upon him- or herself to create a prototype, meanwhile, 
was usually given license to make design decisions that were never brought 
up in group discussions. For example, the hand-held computer was designed 
to have contour lines fitted to the human hand. When this decision was pre- 
sented by one of the designers to the rest of the group, no objections were 
raised or questions asked. 

With plans and prototypes, the language that the designers use became 
immediately (and often productively) mapped onto physical artifacts that all 
members could see. And, because the designers in that project spent almost 
half of their project in research and deliberation, they established a shared 
project space where later plans and prototypes made communal sense. 
Another interesting feature of that process is the necessity, once at the stage 
of plans and prototypes, of role-playing potential users of the artifact, so that 
the design becomes increasingly attached to real situations in the world. 
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The final design consisted of three computerized tools for designers. One 
was a small, pen-based, hand-held computer that was a little larger than the 
size of a palm-top computer. It was meant to be carried at all times and was 
used for sketching and idea generation. Another was a desktop computer, 
measuring two feet by three feet, and functioning as an electronic drafting 
table. Finally, there was a computerized projector for use in client presenta- 
tions. The design did not win the competition, and, unfortunately, the stu- 
dents received no feedback from the client. They did, however, present their 
concepts and prototypes to their professors and the other design students. 

Summary 

In design collaborations of the kind I have reported here — complex 
projects involving multiple individuals, in tasks of considerable uncertainty, 
extending over several months, and requiring the application of expert 
knowledge to unique social situations — there is enormous potential for con- 
flict, frustration, and confusion. I have presented here what I believe to be a 
description of one way designers might face the challenges of a relatively 
open-ended project with a multiple client voices, where the client's require- 
ments were not fully negotiated until plans and prototypes were already on 
the table. Until then, the negotiation of requirements was largely a matter of 
adding one verbal artifact onto another or using one to exclude another. 

Perhaps because they had an interdisciplinary and talented faculty at their 
disposal, or because the group of students was itself small and interdiscipli- 
nary, or because the client's approach to the project was open-ended and 
hands-off, this design effort seemed less proolematic than the other projects 
examined in this panel. Shielded in some sense from external requirements 
and inter-group negotiations, these designers had a good opportunity to 
develop internal processes and products without interference from outside the 
team. That is, there were no alternatives here to what the group ultimately 



Collaborative Invention in Computer Prototype Design: Negotiating Group Processes and Artifacts October 21 , W4 



12 



produced. Still, I believe this project represents a successful balance between 
early research and group discussion (about requirements and criteria particu- 
larly) — primarily an affair of coordinating verbal articulations of the task 
across individuals — and later planning and prototyping that required a 
cycling between perceptually-shared and evolving objects and a set of evolv- 
ing verbal accompaniments to those objects. 
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